home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Technotools
/
Technotools (Chestnut CD-ROM)(1993).ISO
/
lantools
/
atell
/
atell.doc
< prev
next >
Wrap
Text File
|
1992-08-01
|
100KB
|
1,936 lines
COPYRIGHT
The program to which this file relates contains source code made available by
IBM on an AS IS basis. Anyone receiving the source code is considered to be
licensed under IBM copyrights to use the IBM-provided source code in any way
he or she deems fit, including copying it, compiling it, modifying it and
redistributing it, with or without modifications. No license under IBM
patents or patent applications is to be implied from this copyright license.
Any user of the program should understand that IBM cannot provide technical
support for the program and will not be responsible for any consequences of
use of the program.
Any person who transfers the source code or any modified version of the
source code must include the IBM copyright notice, this paragraph and the
preceding two paragraphs in documentation accompanying the source code.
AUTHOR
Peter J. Schwaller
Internet: pjs@ralvm6.vnet.ibm.com
CompuServe: 76711,371
IBM VNET: PJS at RALVM6
Phone: (919) 254-4376
IBM Tie-line: 8-444-4376
Date: July 31, 1992
+---------------------------------------------------------------------------+
| |
| Availability |
| |
+---------------------------------------------------------------------------+
This sample program and source files are also available on CompuServe through
the APPC Information Exchange. To get to the APPC forum just type 'GO APPC'
from any CompuServe prompt. The samples are available in the Sample Programs
library section. Just search on the keyword CPICPGMS to find all the samples
in this series.
Updates for the sample programs and support for many more CPI-C platforms
will also be made available on CompuServe.
+---------------------------------------------------------------------------+
| |
| Terminology |
| |
+---------------------------------------------------------------------------+
TERM DEFINITION
TRANSACTION An exchange between two programs that accomplishes a
particular action or result. Transaction programs are written
in pairs, with both sides of the transaction cooperating to
achieve a result. The sides of a transaction program are
known as "client" and "server."
Examples of transactions are:
o sending a simple message
o executing a specified procedure or task
o updating a database entry
CLIENT Identifies the initiator of a transaction. The client must
specify the name of the other side of the transaction, known
as the server. The term client can refer to either a program
or a computer.
SERVER Identifies the receiver of a transaction. The server does not
need to know the name of the client side of the transaction.
PARTNER COMPUTER
Identifies the "other" side of a transaction. The partner of
the client is the server, and vice versa.
DESTINATION The name used on the client to identify the server.
APPC PLATFORM Refers to the APPC implementation code running on a given
computer.
+---------------------------------------------------------------------------+
| |
| User's Guide |
| |
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
| |
| What Is ATELL? |
| |
+---------------------------------------------------------------------------+
ATELL is a sample program that allows a workstation user to send a message to
another workstation. ATELL is written in the C language and uses the IBM SAA
Common Programming Interface for Communications (CPI-C).
ATELL is made up of two transaction programs; ATELL, which runs on the client
side, and ATELLD, which runs on the server side.
+---------------------------------------------------------------------------+
| |
| Using ATELL |
| |
+---------------------------------------------------------------------------+
The simplest way to use ATELL is to specify only the destination and the
message.
ATELL destination Howdy, pardner.
What you actually specify in place of "destination" is described below.
This command will send the message "Howdy, pardner." to the destination
computer specified. The ATELLD program on the destination computer will show
the message on the computer. The method used for displaying the message may
vary on different operating systems.
The following describes all of the ATELL parameters:
ATELL [optional parameters] destination message
The destination and message are the only required parameters. You may
specify any number of the additional parameters. If you specify any
parameter more than once, the only the last parameter value will be used.
PARAMETER EXPLANATION
destination
Identifies the partner computer on which the ATELLD server program
runs.
May be either a CPI-C symbolic destination name or a partner LU
name.
If the destination is a CPI-C symbolic destination name, it must be
1 to 8 characters and must be configured in your platform's
symbolic destination name table (see Configuration Guide below).
If the destination is a partner LU name, the format varies from
platform to platform. See the Configuration Guide section for your
platform for more information about configuring and specifying
partner LU names.
message
The message text to be sent to the destination computer
-m mode_name
mode name (default: "#INTER")
-t tp_name
the TP name to start on the partner (default: "ATELLD")
-u userid
This is the userid that will be send to the partner. The userid
can be 1-8 characters in length. You should use this parameter
when the destination transaction program has been configured to
require security. One indication that the destination transaction
program requires security is a CPI-C return code of
XC_SECURITY_NOT_VALID.
Specifying this parameter implies the conversation will use CPI-C
security=PROGRAM. A password must also be specified. If a userid
is specified without a password, ATELL will prompt the user for a
password.
-p password
This is the password that will be send to the partner. The
password can be 1-8 characters in length.
-n
This parameter forces ATELL to use NO security on the conversation.
(CPI-C security=NONE). This should be used when you receive a
CPI-C return code of XC_SECURITY_NOT_VALID, but the destination
transaction program is not configured to require security.
+---------------------------------------------------------------------------+
| |
| Configuration Guide for ATELL |
| |
+---------------------------------------------------------------------------+
The ATELL program consists of two sides: the client computer side and the
server computer side. On the client computer side, the user starts up the
ATELL program and specifies what actions should be taken. As a result, the
ATELLD program is started on the server computer side. The ATELL and ATELLD
programs then communicate using CPI-C and complete the transaction.
In order to get the client computer and the server computer to talk to each
other, both computers must be configured. This configuration involves
defining certain APPC information to the ATELL programs and to the APPC
platform on the computer.
The rest the Configuration Guide is divided into the following sections:
o APPC Configuration Overview
This section describes the APPC information that must be provided to the
APPC platform. If you are not familiar with APPC terminology or
configuration, you should read this section.
o Configuration Information for Specific Platforms
These are the actual steps that should be done on the client computer and
server computer. The directions are grouped by APPC platform. You
should find the section for your platforms, and follow the steps
indicated. The following platforms are described in this Configuration
Guide:
- Networking Services/DOS
- Networking Services/2 or Extended Services
- VM SP 6 or VM ESA
- AS/400
- MVS
- AIX SNA Services
+---------------------------------------------------------------------------+
| |
| APPC Configuration Overview |
| |
+---------------------------------------------------------------------------+
In order to successfully communicate with APPC from one computer to another,
you need to configure some information in your APPC platform. This
information consists of:
o How to physically connect to another computer.
You tell your APPC platform how to physically connect to another computer
by defining a link. The link definition tells APPC information about how
to connect to the partner computer, including data link control
information. The data link control represents the physical connection
(token-ring, SDLC, Ethernet, etc.) between two computers. To connect to
the partner computer, the APPC link definition specifies both a data link
control and addressing information specific to that data link control.
For example, if you are using token ring as your data link control, you
will need to specify a token ring address in your link definition. Some
data link controls, may not require any address information, since the
partner computer is implied to be on the other end of the physical
connection. This is common with SDLC leased lines.
o How to identify and find the correct server computer.
Computers are identified in APPC by their fully qualified LU name. The
fully qualified LU name consists of two parts: a network name and an LU
name, concatenated with a period. For example:
USIBMNR.NR55069I
Both the client and server computers must have fully qualified LU names
defined.
LU names are viewed relative to the computer on which they are defined:
there are local LUs and there are partner LUs which are on partner
computers. The local LU name for any given computer is the partner LU
name as viewed from another computer, and vice versa.
Each APPC platform must define at least one local LU, which must be
unique within the network. Since there are only up to 8 characters with
which to create a unique LU name, this can be somewhat challenging in
networks with many computers. Some possible naming conventions for LUs
include:
- Assigning consecutive LU names (alphabetically increasing) under
central administration control.
- Incorporating something that is already unique to each computer.
Examples include:
-- Serial number of the computer
-- Person number of the user
-- Unique userid of the user
On some APPC platforms, you must predefine the list of partner LUs that
the computer will be able to communicate with. Other platforms allow you
to use any fully qualified LU name without having defined it beforehand.
The APPC platform will then dynamically find that LU in the network.
o What kind of connection should be made with the server computer.
When the ATELL client program requests a connection with a partner LU,
the APPC platform establishes what is called a session between the local
LU and the partner LU. The simplest session that can be established
occurs when the client computer and the server computer are directly
connected with a single APPC link. The session goes directly from the
client computer to the server computer.
If your network is larger and more complex, the client computer may be
connected to a network node computers rather than directly to the server
computer. In this case, the session that is established may pass through
other computers in the network. To add to the complexity, there may be
different paths through the network.
The network will always choose the best path through the network for your
application. Since different applications have different needs, APPC
provides a way for the application to specify the route characteristics
that are best for that application. The application specifies a mode
name which contains all the routing characteristics required by the
application. The characteristics associated with a mode include:
- Turnaround time
How fast must data get through the network?
- Throughput
How much data can get through the network?
- Cost
Are you paying for physical connections between computers?
Two modes which are commonly supplied with APPC platforms are #BATCH and
#INTER. The definition for #BATCH specifies a path with good throughput
characteristics. The definition for #INTER specifies a path with good
turnaround time. If your platform does not supply a definition for these
modes, you can either define them on your platform, or use some other
mode that is already defined by specifying the mode name when you start
the ATELL client program.
o How to identify and start the correct program on the server computer.
When the client computer establishes a connection with the server
computer, the server computer must make that connection with a particular
server program. To help the server computer identify the server program,
a transaction program name is sent from the client computer.
The server program is identified by this transaction program (TP) name.
The TP name is a 1 to 64 byte string. Because the actual executable
program names can be different on various computers, the TP name is used
as a common identifier or an alias for the real program name. In many
cases, the TP name and the real program name will be identical.
On the client computer, the TP name is specified by the ATELL client
program and is the first thing sent by the client APPC platform to the
server APPC platform. The client computer does need to have a TP name
definition configured.
The server APPC platform then needs to know how to correlate the received
TP name with an actual program. This is done through a TP definition,
which tells the server APPC platform which program should be started and
the application parameters and characteristics associated with the
program. Some common things that can be configured are:
- The name and location (e.g., subdirectory) of the server program
- A list of users who can use the server program
- Parameters that should be passed to the program when it is started
+---------------------------------------------------------------------------+
| |
| Platform Specific Configuration |
| |
+---------------------------------------------------------------------------+
The following steps have been described for each APPC platform that ATELL has
been tested with (see the list above in the Configuration Guide for ATELL
section).
Each platform will have the following information:
o General configuration tools
- Where and how configuration changes are made
- How to make your configuration changes take effect
o Configuration changes common to client and server computers
o Configuration changes specific to the client computer
How to specify and identify where your server is and how to reach your
server.
o Configuration changes specific to the server computer
How to specify which clients can use the server and what server program
to start when the TP arrives.
Each platform also requires data link control configuration information. In
all of the examples, token ring data link control configuration will be
shown. For information about configuring other data link controls, see the
documentation for the specific platform.
+---------------------------------------------------------------------------+
| |
| Configuration for Networking Services/DOS |
| |
+---------------------------------------------------------------------------+
o General configuration tools
- Where and how configuration changes are made
All configuration changes for Networking Services/DOS are made in the
Networking Services/DOS configuration file. To make changes to your
configuration, you must edit the Networking Services/DOS
configuration file according to the directions below. The default
configuration file is named CONFIG.NSD and is usually in the \NSD
subdirectory. You may use another file name, but you will have to
specify that name explicitly when you use the NSD command (see
below).
- How to make your configuration changes active
After you have edited your Networking Services/DOS configuration
file, you should use the NSD command to start NSD and activate your
configuration changes. If you are using the default configuration
file, you should use:
nsd start
If you are using another Networking Services/DOS configuration file,
you should use:
nsd start FILENAME
o Configuration changes common to client and server computers
- Defining a local LU
Include an "nsdn" statement in your Networking Services/DOS
configuration file:
nsdn NETWORK_NAME.CLIENT_LU
The name specified by the "nsdn" entry must be unique throughout your
network.
- Defining a partner LU
-- If you are directly connected to your partner computer, include
"nsdc" and "trld" entries in your Networking Services/DOS
configuration file. You must specify both the partner LU name
and the token ring destination address of the partner computer.
For example:
nsdc lan
trld SERVER_LU,400000000001
-- If you are connected to your partner computer through a network
node, "nsdc," and "trld" entries in your Networking Services/DOS
configuration file. For example:
nsdc lan
trld NN_LU,600000000002
In this example, we specify a physical connection to our network
node, specifying the LU name of the network node (NN_LU) and the
token ring destination address. We then specify that the LU name
SERVER_LU can be reached through the network node NN_LU.
In both cases, change the token ring destination address in the
example to the address of the partner computer you are connecting to.
- Defining a link to a partner computer or to the network node
The definition of the link has already been done in the partner LU
section above.
- Defining a mode
Since Networking Services/DOS has already defined the IBM supplied
mode names in the supplied MODE.NSD file, including #INTER, no mode
definitions on Networking Services/DOS are needed for ATELL.
o Configuration changes specific to the client computer
No special configuration is needed for Networking Services/DOS to
configure the ATELL client.
o Configuration changes specific to the server computer
Consult your Networking Services/DOS documentation for information on how
to run server programs in a DOS or Windows environment.
+---------------------------------------------------------------------------+
| |
| Configuration for Extended Services and Networking Services/2 (OS/2) |
| |
+---------------------------------------------------------------------------+
o General configuration tools
- Where and how configuration changes are made
To configure Extended Services and Networking Services/2 use either
the Configuration Management panels or edit the Node Definitions File
(NDF). Although the following examples show Node Definitions File
commands, you can enter the same information on the Configuration
Management panels. Your Node Definitions File file will have the
same filename as your Communications Manager configuration file, but
with a file extension of "NDF."
- How to make your configuration changes active
You must verify the configuration file after changes are made to the
configuration. If you have edited the Node Definitions File, run
APPNV from an OS/2 Command prompt with the /e option to verify and
update your configuration. For example:
appnv WRKBASE.NDF /e
o Configuration changes common to client and server computers
- Defining a local LU
During the Extended Services and Networking Services/2 installation
process, at least one local LU was configured. This is the LU that
will be used when you run the ATELL client. When your computer is
acting as a server, this is the LU name that should be configured on
the client platform as the partner LU.
You can find your local LU in the DEFINE_LOCAL_CP command In the
following Node Definitions File excerpt:
define_local_cp
fq_cp_name(NETWORK_NAME.CLIENT_LU)
cp_alias(mylu)
node_id(x'50000')
node_type(en);
The local LU is NETWORK_NAME.CLIENT_LU.
- Defining a partner LU
Since both Extended Services and Networking Services/2 support APPN,
you do not need to define partner LU names.
When your computer is the client, you will simply need to specify the
fully qualified name of your partner LU. This fully qualified name
includes the network name and LU name concatenated with a period. To
enable any partner to call you when your computer is a server, make
sure your Node Definitions File contains the following:
define_defaults
implicit_inbound_plu_support(yes);
An additional feature of defining partner LUs is that you can provide
an alias for the actual partner LU name. For example, you could
define "server" to be an alias for NETWORK_NAME.SERVER_LU. Alias are
case sensitive; "SERVER" is a different alias than "server."
If you choose to define partner LUs, either to provide an alias for
use when running the ATELL client, or to restrict the names of
partner clients that can contact you, use a "define_partner_lu"
command as follows:
define_partner_lu
fq_partner_lu_name(NETWORK_NAME.SERVER_LU)
partner_lu_alias(server);
- Defining a link to a partner computer or to the network node
-- To define a link directly to your partner, your Node Definitions
File should contain a "define_link" command,
define_logical_link
link_name(link)
fq_adjacent_cp_name(NETWORK_NAME.SERVER_LU)
adjacent_node_type(len)
dlc_name(ibmtrnet)
adapter_number(0)
destination_address(x'400000000001')
cp_cp_session_support(no)
activate_at_startup(no);
-- To define a link to your network node, your Node Definitions File
should contain a "define_link" command,
define_logical_link
link_name(link)
adjacent_node_type(nn)
dlc_name(ibmtrnet)
adapter_number(0)
destination_address(x'600000000002')
cp_cp_session_support(yes)
activate_at_startup(yes);
Note that the CP name of the network node does not have to be
specified on the "define_link" command.
In both cases, change the destination address in the example to the
address of the partner computer you are connecting to.
In order to allow other computers to configure links to your computer,
you will need to give them your local token ring address. To find out
your own token ring address, look in the ACSLAN.LOG file in the \CMLIB
subdirectory if you are using Networking Services/2 or the LANTRAN.LOG
file in the \IBMCOM subdirectory if you are using Extended Services.
Your token ring address appears in a line similar to the following:
Adapter 0 is using node address 400000000000.
o Configuration changes specific to the client computer
No special configuration is needed for Extended Services or Networking
Services/2 to configure the ATELL client.
o Configuration changes specific to the server computer
- Defining the TP
Configure the ATELLD program as follows. Make sure the "filespec"
specifies the directory where the ATELLD.EXE program resides.
define_tp
tp_name(ATELLD)
filespec(C:\SAMPLES\ATELL\ATELLD.EXE)
tp_operation(nonqueued_am_started)
program_type(vio_windowable);
The "tp_operation" field indicates that a new copy of the ATELLD.EXE
program should be started for every new client. The "program_type"
field indicates that the program should be run in an OS/2 Window.
Note that TP names are case sensitive. The ATELLD must be typed in
all upper case.
+---------------------------------------------------------------------------+
| |
| Configuration for VM |
| |
+---------------------------------------------------------------------------+
+--- WARNING ---------------------------------------------------------------+
| |
| The configuration instructions for VM have not been fully tested. If you |
| have problems, please contact the author (indicated at the top of this |
| file). |
| |
+---------------------------------------------------------------------------+
o General configuration tools
- Where and how configuration changes are made
There are four places where configuration changes are required for
VM:
1. The CP directory entry must be changed to include definition of
the server.
2. The client must define a local directory entry that describes the
path that VTAM uses to find the server.
3. The APPC VTAM Service Machine (AVS) must be configured to know
how to map requests between VTAM and local resources.
4. VTAM must be configured so that it knows about the APPC gateway
as well as any remote clients or servers.
More detailed information on the configuration can be found in
CONNECTIVITY PLANNING, ADMINISTRATION, AND OPERATION, SC24-5448.
- How to make configuration changes active
Once CP directory entries are put online (DIRMAINT is typically used
for this), the server is ready. After adding directory entries to
the local directory the SET COMDIR command must be issued to activate
the changes. The major nodes of VTAM affected by the changes must be
restarted for VTAM changes to become active. AVS can either be
restarted, or commands can be issued to the virtual machine to make
any new gateways known.
o Configuration common to client and server computers
- Define AVS Gateway LU to VTAM
The AVS gateway is a gateway between local resources (programs
running in virtual machines) and the VTAM network. To communicate
through VTAM it acts as a VTAM application. It therefore must be
defined in a VTAM application major node. An example is shown below:
APLAVS VBUILD TYPE=APPL
SERVER_LU APPL APPC=YES, X
AUTH=(ACQ), X
ACBNAME=SERVER_LU, X
AUTOSES=0, X
AUTHEXIT=YES, X
MODETAB=APPCMODE, X
DLOGMOD=#INTER, X
PARSESS=YES, X
SECACPT=NONE
This definition uses a logmode name of #INTER. This must be the mode
used on the bind from the client, if it is in the VTAM network.
Logmode #INTER must also be assembled and link-edited into a
simulated partitioned data set (PDS) accessible by VTAM. In the
example below it would be in member APPCMODE. The PDS used is
typically VTAMUSER. The following sample mode table contains
definitions for typical APPC modes.
APPCMODE MODETAB
**********************************************************************
* LOGMODE TABLE ENTRY FOR RESOURCES CAPABLE OF ACTING *
* AS LU 6.2 DEVICES @R495812 @KFC*
**********************************************************************
SNASVCMG MODEENT LOGMODE=SNASVCMG,FMPROF=X'13',TSPROF=X'07', *
PRIPROT=X'B0',SECPROT=X'B0',COMPROT=X'D0B1', *
RUSIZES=X'8686',ENCR=B'0000',SSNDPAC=7, *@KFC* *
PSERVIC=X'060200000000000000000300', *@R495812* *
SRCVPAC=7,PSNDPAC=7,TYPE=0 *@KFA*
TITLE '#BATCH' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR BATCH SESSIONS ON RESOURCES CAPABLE *
* OF ACTING AS LU 6.2 DEVICES *
* @KFA*
***********************************************************************
#BATCH MODEENT LOGMODE=#BATCH, *@KFA* *
ENCR=B'0000',SSNDPAC=3, *@KFA* *
SRCVPAC=3,PSNDPAC=3 *@KFA*
TITLE '#INTER' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR INTERACTIVE SESSIONS ON RESOURCES *
* CAPABLE OF ACTING AS LU 6.2 DEVICES *
* @KFA*
***********************************************************************
#INTER MODEENT LOGMODE=#INTER, *@KFA* *
ENCR=B'0000',SSNDPAC=7, *@KFA* *
SRCVPAC=7,PSNDPAC=7 *@KFA*
TITLE '#BATCHSC' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR BATCH SESSIONS REQUIRING SECURE *
* TRANSPORT ON RESOURCES CAPABLE OF ACTING AS LU 6.2 *
* DEVICES *
* @KFA*
***********************************************************************
#BATCHSC MODEENT LOGMODE=#BATCHSC, *@KFA* *
ENCR=B'0000',SSNDPAC=3, *@KFA* *
SRCVPAC=3,PSNDPAC=3 *@KFA*
TITLE '#INTERSC' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR INTERACTIVE SESSIONS REQUIRING *
* SECURE TRANSPORT ON RESOURCES CAPABLE OF ACTING AS *
* LU 6.2 DEVICES *
* @KFA*
***********************************************************************
#INTERSC MODEENT LOGMODE=#INTERSC, *@KFA* *
ENCR=B'0000',SSNDPAC=7, *@KFA* *
SRCVPAC=7,PSNDPAC=7 *@KFA*
TITLE 'CPSVCMG' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR CP-CP SESSIONS ON RESOURCES CAPABLE *
* OF ACTING AS LU 6.2 DEVICES *
* @KFA*
***********************************************************************
CPSVCMG MODEENT LOGMODE=CPSCVMG, *@KFA* *
RUSIZES=X'8686',ENCR=B'0000', *@KFA* *
SSNDPAC=7,SRCVPAC=7,PSNDPAC=7 *@KFA*
MODEEND
END
- Define AVS Gateway to AVS Service Machine
The gateway defined to VTAM must also be defined for the AVS virtual
machine. This can be done in the AGWPROF GCS, which is the profile
information for the AVS service machine. An example is shown below:
/*********************************/
/* */
/* SAMPLE AGWPROF GCS FOR AVS */
/* */
/*********************************/
Trace O
'AGW ACTIVATE GATEWAY SERVER_LU PRIVATE USERID VMSERVER'
'AGW CNOS SERVER_LU CLIENT_LU #INTER 2 0 2'
The above example activates a private gateway called SERVER_LU, which
is used exclusively by a server running under userid VMSERVER. It
also issues a CNOS (change number of sessions) to establish two
sessions with a device in the VTAM subarea network called CLIENT_LU.
o Configuration specific to the client computer
The user must define a directory that tells APPC how to find the target
server, and other parameters of the conversation. These are kept in a
UCOMDIR NAMES file, similar to the NAMES file used by such things as the
NOTE exec. An example is shown below:
:nick.SERVER
:luname.SERVER_LU CLIENT_LU
:tpn.ATELLD
:modename.#INTER
:security.NONE
This tells APPC/VM that a resource called SERVER can be located in the
VTAM subarea network by using gateway SERVER_LU to establish a session
with CLIENT_LU using logmode #INTER. The transaction program (TPN) to
start on that computer is called ATELLD. Once this is added to the
directory, the changes are activated by issuing:
SET COMDIR RELOAD
In addition, VTAM must be able to find the partner LU SERVER_LU. In VTAM
V3R4, a session management exit may be defined to do this function.
Based on the LU name, the exit can be customized to determine which
Adjacent Link Station (this would typically be a PU2.1) to send the bind
to. For pre-V3R4 VTAMs the LU must be defined. An example of a
definition for a Switched Major Node is given below:
PCSWNODE VBUILD TYPE=SWNET,MAXGRP=10,MAXNO=10
SERVER_LUP PU ADDR=04,ISTATUS=ACTIVE,PACING=7, X
MAXDATA=2044,IDBLK=05D,IDNUM=00100, X
MAXOUT=7,PASSLIM=7,MAXPATH=1, X
PUTYPE=2,LANSW=YES, X
MODETAB=AGWTAB,DLOGMOD=#INTER X
SERVER_LU LU LOCADDR=0,ISTATUS=ACTIVE
o Configuration specific to the server computer
In the AVS virtual machine definition, VMSERVER was configured as a
private server, and an LU definition in VTAM (SERVER_LU) assigned to it.
The following commands must be included in VMSERVER PROFILE EXEC to
configure it to run as a private resource server:
'SET SERVER ON'
'SET FULLSCREEN OFF'
'SET AUTOREAD OFF'
The following must be added to the $SERVER$ NAMES file on the VMSERVER
userid:
:nick.ATELLD :list.*
:module.ATELLD
+---------------------------------------------------------------------------+
| |
| Configuration for MVS. |
| |
+---------------------------------------------------------------------------+
+--- WARNING ---------------------------------------------------------------+
| |
| The configuration instructions for MVS have not been fully tested. If |
| you have problems, please contact the author (indicated at the top of |
| this file). |
| |
+---------------------------------------------------------------------------+
o Where and how configuration changes are made
APPC/MVS configuration is detailed in Planning: APPC
Management(GC28-1110). In general it involves defining parameters for
two subsystems, APPC and ASCH. They run in separate address spaces. The
APPC address space handles the actual communications, while ASCH is a
scheduler that initiates transaction programs based on receipt of
incoming attaches. Beyond these two address spaces, some configuration is
required in VTAM.
MVS/ESA 4.2 or later is required for APPC/MVS.
o The APPC/MVS Address Spaces
Both APPC and ASCH have parmlib members that contain configuration
information for the respective address spaces. Samples are shipped with
MVS/ESA 4.2 or higher in SYS1.SAMPLIB. These samples can be modified and
copied into SYS1.PARMLIB to provide the parameters necessary to start the
respective subsystems. Their names in SYS1.SAMPLIB are APPCPMXX and
ASCHPMXX. The "XX" must be changed to a numeric value when the members
are placed in SYS1.PARMLIB. Below is a sample SYS1.PARMLIB(APPCPM00),
which is the default used at startup.
/***PROPRIETARY_STATEMENT********************************************/
/* */
/* */
/* LICENSED MATERIALS - PROPERTY OF IBM */
/* THIS MACRO IS "RESTRICTED MATERIALS OF IBM" */
/* 5695-047 (C) COPYRIGHT IBM CORP. 1990 */
/* SEE COPYRIGHT INSTRUCTIONS */
/* */
/* STATUS= HBB4420 */
/* */
/***END_OF_PROPRIETARY_STATEMENT*************************************/
/********************************************************************/
/* This is a sample APPCPM00 member of SYS1.PARMLIB. */
/* */
/* APPCPM00 parmlib members contain startup, default and */
/* customization values for APPC/MVS. They also contain */
/* information indicating the correspondence between */
/* logical unit(LU) names and transaction schedulers. */
/* */
/* This member illustrates the syntax of the LUADD, LUDEL, */
/* LMADD, LMDEL and SIDEINFO statement types. */
/* */
/* NOTE: */
/* */
/* This SAMPLIB member is only an example. The value */
/* represented on each statement is not necessarily an */
/* IBM-recommended value. */
/* Installations may use this member as a sample, and */
/* modify it according to their needs. */
/* */
/* DO NOT COPY AND USE THIS SAMPLE WITHOUT PROVIDING THE */
/* NECESSARY SUPPORT FOR THE VALUES IT NAMES. */
/* */
/********************************************************************/
/********************************************************************/
/* */
/* Define a local LU with the name TOMVSAP to the APPC/MVS */
/* configuration. */
/* */
/* Note: */
/* */
/* 1. The VSAM data set specified on the TPDATA keyword */
/* must be already defined to the system, otherwise an */
/* error message will be issued. */
/* */
/* 2. If this LU is intended to handle network traffic, */
/* then the LU name MVSLU01 must correspond to the */
/* ACBNAME operand of an application definition (APPL) */
/* statement in the SYS1.VTAMLST system library and */
/* the ACBNAME & APPL name must match. */
/* */
/********************************************************************/
LUADD ACBNAME(TOMVSAP) /* Add local LU MVSLU01 to the */
/* APPC/MVS configuration */
SCHED(ASCH) /* Specify that the APPC/MVS */
/* transaction scheduler is associated */
/* with this LU name */
BASE /* Designate this LU as the base LU */
TPDATA(SYS1.APPCTP) /* Specify that VSAM data set */
/* SYS1.APPCTP is the permanent */
/* repository for the TP profiles */
/* for this LU */
TPLEVEL(USER) /* Specify the search order for TP */
/* profiles as : */
/* 1. TP profiles associated with */
/* a specific user */
/* 2. TP profiles associated with */
/* a group of users */
/* 3. TP profiles associated with */
/* all users of the LU name */
/********************************************************************/
/* */
/* Specify that Side information is to be kept in VSAM */
/* data set SYS1.APPCSI. */
/* */
/* Note: */
/* */
/* 1. If the SIDEINFO statement is specified with no operands */
/* then the default will be: */
/* o DATASET(SYS1.APPCSI) */
/* */
/* 2. The VSAM data set specified on the DATASET keyword */
/* must be already defined to the system, otherwise an */
/* error message will be issued. */
/* */
/********************************************************************/
SIDEINFO DATASET(SYS1.APPCSI) /* Specify that VSAM data set */
/* SYS1.APPCSI is the permanent */
/* repository for the side */
/* information */
Below is a sample ASCHPM00 parmlib member.
/*01* PROPRIETARY STATEMENT= */
/***PROPRIETARY_STATEMENT********************************************/
/* */
/* */
/* LICENSED MATERIALS - PROPERTY OF IBM */
/* THIS MACRO IS "RESTRICTED MATERIALS OF IBM" */
/* 5695-047 (C) COPYRIGHT IBM CORP. 1990 */
/* SEE COPYRIGHT INSTRUCTIONS */
/* */
/* STATUS= HBB4420 */
/* */
/***END_OF_PROPRIETARY_STATEMENT*************************************/
/********************************************************************/
/* This is a sample ASCHPM00 member of SYS1.PARMLIB. */
/* */
/* ASCHPMxx parmlib members contain startup, default and */
/* customization values for the APPC/MVS transaction scheduler. */
/* These parmlib members define classes of transaction */
/* initiators in which a transaction program can run. */
/* */
/* This member illustrates the syntax of the CLASSADD, */
/* OPTIONS and TPDEFAULT statement types. */
/* */
/* NOTE: */
/* */
/* This SAMPLIB member is only an example. The value */
/* represented on each statement is not necessarily an */
/* IBM-recommended value. */
/* Installations may use this member as a sample, and */
/* modify it according to their needs. */
/* */
/* DO NOT COPY AND USE THIS SAMPLE WITHOUT PROVIDING THE */
/* NECESSARY SUPPORT FOR THE VALUES IT NAMES. */
/* */
/********************************************************************/
/********************************************************************/
/* */
/* Define a class of transaction initiators to be added to */
/* the APPC/MVS transaction scheduler configuration. */
/* The class has the following characteristics: */
/* o Class name - FAST */
/* o Maximum number of transaction initiators allowed - 10 */
/* o Minimum number of transaction initiators to be */
/* brought up - 2 */
/* o Response time goal - 0.02 seconds */
/* o Maximum size of the job log for TPs - 500 messages */
/* */
/********************************************************************/
CLASSADD CLASSNAME(FAST) /* Specify the name of the class to be */
/* added */
MAX(10) /* Specify that the maximum number */
/* of transaction initiators allowed */
/* for this class is 10 */
MIN(2) /* Specify that the minimum number */
/* of transaction initiators to be */
/* brought up for this class is 2 */
RESPGOAL(.02) /* Specify that the response time */
/* goal for transaction programs */
/* executing within this class is 0.02 */
/* seconds */
MSGLIMIT(500) /* Specify that the maximum size of */
/* the job logs for TPs is 500 */
/* messages */
/********************************************************************/
/* */
/* Define a class of transaction initiators to be added to */
/* the APPC/MVS transaction scheduler configuration. */
/* The class has the following characteristics: */
/* o Class name - SLOW */
/* o Maximum number of transaction initiators allowed - 1 */
/* o Minimum number of transaction initiators to be */
/* brought up - 0 */
/* o Response time goal - 1 second */
/* o Maximum size of the job log for TPs - 500 messages */
/* */
/* Note: */
/* */
/* 1. Defaults are used if keywords are omitted from a */
/* CLASSADD statement except for the CLASSNAME. */
/* */
/* 2. The following defaults will be taken for this entry: */
/* o MAX(1) */
/* o MIN(0) */
/* o RESPGOAL(1) */
/* o MSGLIMIT(500) */
/* */
/********************************************************************/
CLASSADD CLASSNAME(SLOW) /* Specify the name of the class to be */
/* added */
/********************************************************************/
/* */
/* Define the APPC/MVS transaction scheduler configuration */
/* default class in which to run transaction programs when a */
/* classname is not specified in the TP profile, and define */
/* the subsystem to which all newly created APPC/MVS */
/* transaction initiators are assigned. */
/* */
/* Note: */
/* */
/* 1. There is no default for the DEFAULT keyword. */
/* */
/* 2. The default SUBSYS(Primary subsystem name) will only */
/* apply when there is no prior SUBSYS defined to the */
/* APPC/MVS transaction scheduler configuration. */
/* */
/********************************************************************/
OPTIONS DEFAULT(SLOW) /* Specify the default class */
SUBSYS(JES2) /* Specify the name of a subsystem */
Note that both SYS1.APPCTP and SYS1.APPCSI must be defined prior to
starting APPC and ASCH. Below are sample jobs to do these tasks:
//ATBTP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
/*JOBPARM LINES=9999,TIME=1440
//*************************************************************/
//* */
//* THIS IS A SAMPLE DEFINITION FOR A VSAM KEY SEQUENCED */
//* DATA SET (KSDS) TO CONTAIN APPC TP PROFILES. YOU CAN */
//* USE THIS SAMPLE OR MODIFY IT. */
//* */
//* A TP PROFILE ENTRY CONTAINS IDENTIFICATION, SECURITY, */
//* AND SCHEDULING INFORMATION FOR A TP THAT RESPONDS TO */
//* AN INBOUND ALLOCATE REQUEST. */
//* */
//* */
//* SHAREOPTIONS(3 3) - */
//* */
//* MUST BE (3 3) BECAUSE THE APPC SUBSYSTEM REFERENCES */
//* THIS KSDS IN SUCH A WAY THAT IT MUST BE FULLY */
//* SHARED. */
//* */
//* RECORDSIZE(3824 7024) - */
//* */
//* THIS IS THE AVERAGE AND MAXIMUM RECORD SIZE. */
//* */
//* AVERAGE CALCULATION: */
//* */
//* TP PROFILE KEY 112 BYTES */
//* NON JCL DATA (maximum possible) 512 BYTES */
//* JCL (40 LINE OF 80 BYTES) 3200 BYTES */
//* ------------ ------------- */
//* TOTAL 3824 BYTES */
//* */
//* MAXIMUM CALCULATION: */
//* */
//* TP PROFILE KEY 112 BYTES */
//* NON JCL DATA (maximum possible) 512 BYTES */
//* JCL (80 LINE OF 80 BYTES) 6400 BYTES */
//* ------------ ------------- */
//* TOTAL 7024 BYTES */
//* */
//* */
//* THIS KSDS IS DESIGNED TO HOLD 300 TP PROFILES */
//* BUT CAN EXPAND TO HOLD AN ADDITIONAL 150. */
//* */
//* CHANGES: */
//* */
//* - REPLACE CNMSTC WITH THE NAME OF YOUR VOLUME. */
//* - REPLACE, IF NECESSARY, SYS1.APPCTP WITH THE NAME */
//* OF YOUR TP PROFILE DATASET. */
//* - REPLACE, IF NECESSARY, THE RECORDS VALUES WITH THE */
//* NUMBER OF TP PROFILES THE KSDS IS DESIGNED TO HOLD */
//* AND THE EXPANSION NUMBER. */
//* */
//*************************************************************/
//TPSAMPLE EXEC PGM=IDCAMS
//CNMSTC DD DISP=OLD,UNIT=3380,VOL=SER=CNMSTC
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//AMSDUMP DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER (NAME(SYS1.APPCTP) -
VOLUMES(CNMSTC) -
INDEXED REUSE -
SHAREOPTIONS(3 3) -
RECORDSIZE(3824 7024) -
KEYS(112 0) -
RECORDS(300 150)) -
DATA -
(NAME(SYS1.APPCTP.DATA)) -
INDEX -
(NAME(SYS1.APPCTP.INDEX))
/*
//ATBSI02 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
/*JOBPARM LINES=9999,TIME=1440
//*************************************************************/
//* */
//* THIS IS A SAMPLE DEFINITION FOR A VSAM KEY SEQUENCED */
//* DATA SET (KSDS) TO CONTAIN APPC SIDE INFORMATION. */
//* YOU CAN USE THIS SAMPLE OR MODIFY IT. */
//* */
//* A SIDE INFORMATION ENTRY CONTAINS THE TRANSLATION OF A */
//* SYMBOLIC DESTINATION NAME THAT IS USED TO INITIATE AN */
//* APPC CONVERSATION. THE SIDE INFORMATION ENTRY CONSISTS */
//* OF: */
//* */
//* SI KEY 112 BYTES */
//* SI DATA 136 BYTES */
//* --------- ----------- */
//* TOTAL 248 BYTES */
//* */
//* THIS KSDS IS DESIGNED TO HOLD 50 SIDE INFORMATION */
//* ENTRIES BUT CAN EXPAND TO HOLD AN ADDITIONAL 25. */
//* */
//* CHANGES: */
//* */
//* - REPLACE CNMSTC WITH THE NAME OF YOUR VOLUME. */
//* - REPLACE, IF NECESSARY, SYS1.APPCSI WITH THE NAME OF */
//* YOUR SIDE INFORMATION REPOSITORY. */
//* - REPLACE, IF NECESSARY, THE RECORDS VALUES WITH THE */
//* NUMBER OF ENTRIES THE KSDS IS DESIGNED TO HOLD */
//* AND THE EXPANSION NUMBER. */
//* */
//*************************************************************/
//SISAMPLE EXEC PGM=IDCAMS
//CNMSTC DD DISP=OLD,UNIT=3380,VOL=SER=CNMSTC
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//AMSDUMP DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER (NAME(SYS1.APPCSI) -
VOLUME(CNMSTC) -
INDEXED REUSE -
SHAREOPTIONS(3 3) -
RECORDSIZE(248 248) -
KEYS(112 0) -
RECORDS(50 25)) -
DATA -
(NAME(SYS1.APPCSI.DATA)) -
INDEX -
(NAME(SYS1.APPCSI.INDEX))
For ATELLD to be scheduled by ASCH, a transaction program (TP) profile
must be created. This information is loaded into the TP profile VSAM
dataset. Below is a sample job to do this:
//ATBTP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
//*************************************************************
//STEP EXEC PGM=ATBSDFMU
//SYSPRINT DD SYSOUT=*
//SYSSDLIB DD DSN=SYS1.APPCTP,DISP=SHR
//SYSSDOUT DD SYSOUT=*
//SYSIN DD DATA,DLM=XX
TPADD
TPNAME(ATELLD)
ACTIVE(YES)
TPSCHED_DELIMITER(##)
TAILOR_SYSOUT(NO)
TAILOR_ACCOUNT(NO)
CLASS(FAST)
TPSCHED_TYPE(STANDARD)
JCL_DELIMITER(END_OF_JCL)
//ATBAPING JOB ,IBMUSER
//STEP1 EXEC PGM=ATELLD
//STEPLIB DD DSN=IBMUSER.LOADLIB,DISP=SHR
// DD DSN=EDC.V2R1M0.SEDCLINK,DISP=SHR
// DD DSN=PLI.V2R3M0.SIBMLINK,DISP=SHR
END_OF_JCL
##
XX
/*
In the above, the load module for ATELLD is assumed to reside in
IBMUSER.LOADLIB. Also, note the CLASS is FAST, and those parameters were
defined in the ASCHPM00 member above.
If ATELL is to use CPI-C side information, the side information must be
loaded into the side information VSAM data set, SYS1.APPCSI. Below is a
sample job to perform this function:
//ATBSI01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
//*************************************************************
//STEP EXEC PGM=ATBSDFMU
//SYSPRINT DD SYSOUT=*
//SYSSDLIB DD DSN=SYS1.APPCSI,DISP=SHR
//SYSSDOUT DD SYSOUT=*
//SYSIN DD *
SIADD
DESTNAME(IBMRTP)
TPNAME(ATELLD)
MODENAME(#INTER)
PARTNER_LU(SERVER_LU)
/*
In the above example, the side information name IBMRTP will designate the
partner TP ATELLD at partner LU SERVER_LU using mode #INTER.
In order to start the two subsystems, the commands:
START APPC,SUB=MSTR
START ASCH,SUB=MSTR
must be issued at the console. These commands use the SYS1.PROCLIB
members APPC and ASCH, shipped with MVS/ESA 4.2 or higher.
o VTAM
The application name for the APPC/MVS LU must be defined. The following
example shows this. While this shows only one LU definition, it is
possible for APPC/MVS to have multiple LU definitions that can be used
for different purposes.
AB7APPLS VBUILD TYPE=APPL
TOMVSAP APPL ACBNAME=TOMVSAP,APPC=YES,AUTOSES=5,DDRAINL=NALLOW, *
DMINWNL=3,DMINWNR=6,DRESPL=NALLOW,DSESLIM=9,EAS=509, *
MODETAB=APPCMODE,SECACPT=CONV,VPACING=2,VERIFY=NONE, *
SRBEXIT=YES,DLOGMOD=#INTER
Note that the LU name (TOMVSAP) matches the name defined in the PARMLIB
member APPCPM00. The default mode name is #INTER, which is included in
mode table APPCMODE. #INTER is an architected mode name. In general,
mode names used should be from the set of architected ones. Below is a
mode table containing these architected modes.
APPCMODE MODETAB
**********************************************************************
* LOGMODE TABLE ENTRY FOR RESOURCES CAPABLE OF ACTING *
* AS LU 6.2 DEVICES @R495812 @KFC*
**********************************************************************
SNASVCMG MODEENT LOGMODE=SNASVCMG,FMPROF=X'13',TSPROF=X'07', *
PRIPROT=X'B0',SECPROT=X'B0',COMPROT=X'D0B1', *
RUSIZES=X'8686',ENCR=B'0000',SSNDPAC=7, *@KFC* *
PSERVIC=X'060200000000000000000300', *@R495812* *
SRCVPAC=7,PSNDPAC=7,TYPE=0 *@KFA*
TITLE '#BATCH' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR BATCH SESSIONS ON RESOURCES CAPABLE *
* OF ACTING AS LU 6.2 DEVICES *
* @KFA*
***********************************************************************
#BATCH MODEENT LOGMODE=#BATCH, *@KFA* *
ENCR=B'0000',SSNDPAC=3, *@KFA* *
SRCVPAC=3,PSNDPAC=3 *@KFA*
TITLE '#INTER' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR INTERACTIVE SESSIONS ON RESOURCES *
* CAPABLE OF ACTING AS LU 6.2 DEVICES *
* @KFA*
***********************************************************************
#INTER MODEENT LOGMODE=#INTER, *@KFA* *
ENCR=B'0000',SSNDPAC=7, *@KFA* *
SRCVPAC=7,PSNDPAC=7 *@KFA*
TITLE '#BATCHSC' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR BATCH SESSIONS REQUIRING SECURE *
* TRANSPORT ON RESOURCES CAPABLE OF ACTING AS LU 6.2 *
* DEVICES *
* @KFA*
***********************************************************************
#BATCHSC MODEENT LOGMODE=#BATCHSC, *@KFA* *
ENCR=B'0000',SSNDPAC=3, *@KFA* *
SRCVPAC=3,PSNDPAC=3 *@KFA*
TITLE '#INTERSC' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR INTERACTIVE SESSIONS REQUIRING *
* SECURE TRANSPORT ON RESOURCES CAPABLE OF ACTING AS *
* LU 6.2 DEVICES *
* @KFA*
***********************************************************************
#INTERSC MODEENT LOGMODE=#INTERSC, *@KFA* *
ENCR=B'0000',SSNDPAC=7, *@KFA* *
SRCVPAC=7,PSNDPAC=7 *@KFA*
TITLE 'CPSVCMG' *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR CP-CP SESSIONS ON RESOURCES CAPABLE *
* OF ACTING AS LU 6.2 DEVICES *
* @KFA*
***********************************************************************
CPSVCMG MODEENT LOGMODE=CPSCVMG, *@KFA* *
RUSIZES=X'8686',ENCR=B'0000', *@KFA* *
SSNDPAC=7,SRCVPAC=7,PSNDPAC=7 *@KFA*
MODEEND
END
This table should be assembled and placed in a dataset defined to STEPLIB
in the VTAM start procedure.
VTAM must also be able to find the partner LU SERVER_LU. In VTAM V3R4, a
session management exit may be defined to do this function. Based on the
LU name, the exit can be customized to determine which Adjacent Link
Station (this would typically be a PU2.1) to send the bind to. For
pre-V3R4 VTAMs the LU must be defined. An example of a definition for a
Switched Major Node is given below:
PCSWNODE VBUILD TYPE=SWNET,MAXGRP=10,MAXNO=10
SERVER_LUP PU ADDR=04,ISTATUS=ACTIVE,PACING=7, X
MAXDATA=2044,IDBLK=05D,IDNUM=00100, X
MAXOUT=7,PASSLIM=7,MAXPATH=1, X
PUTYPE=2,LANSW=YES, X
MODETAB=AGWTAB,DLOGMOD=#INTER X
SERVER_LU LU LOCADDR=0,ISTATUS=ACTIVE
+---------------------------------------------------------------------------+
| |
| Configuration for AS/400 |
| |
+---------------------------------------------------------------------------+
o General configuration tools
- Where and how configuration changes are made
AS/400 configuration is performed through a series of menu driven
panels. You can access these panels either by proceeding through a
series of menu choices, or by entering the command name directly.
- How to make your configuration changes active
Unless specifically noted, all configuration changes are active and
usable as soon as they are entered.
o Configuration changes common to client and server computers
- Defining a local LU During the AS/400 installation process, at least
one local LU was configured. This is the LU that will be used when
you run the ATELL client. When your computer is acting as a server,
this is the LU name that should be configured on the client platform
as the partner LU.
You can find your local LU on the Display Network Attributes panel.
You can find this panel through the following sequence:
define_local_cp fq_cp_name(NETWORK_NAME.CLIENT_LU)
7. Define or change the system
1. Configuration
4. Network management
1. Display network attributes
You will see a panel similar to the following:
Display Network Attributes
System: CLIENT_LU
Current system name . . . . . . . . . . . . . . : CLIENT_LU
Pending system name . . . . . . . . . . . . . :
Local network ID . . . . . . . . . . . . . . . . : NETWORK_NAME
Local control point name . . . . . . . . . . . . : CLIENT_LU
Default local location . . . . . . . . . . . . . : CLIENT_LU
Default mode . . . . . . . . . . . . . . . . . . : BLANK
APPN node type . . . . . . . . . . . . . . . . . : *NETNODE
Maximum number of intermediate sessions . . . . : 200
Route addition resistance . . . . . . . . . . . : 128
Server network ID/control point name . . . . . . :
The local LU is NETWORK_NAME.CLIENT_LU.
- Defining a partner LU and Defining a link to a partner computer or to
the network node
On the AS/400, you can define your partner LU name and a logical link
from the same configuration panel. A controller description is used
to describe all the characteristics of an adjacent computer.
You can access controller descriptions through the CRTCTLAPPC or
CHGCTLAPPC commands (Create/Change Controller Description, APPC).
The following example shows only the fields of the controller
description that need to be changed. You can allow the other fields
to use the defaults.
CRTCTLAPPC
Controller Description > SERVER_LU
Link type > *LAN
Online at IPL > *YES
APPN-capable > *YES
Switched line list > TRLAN
Remote network identifier > NETWORK_NAME
Remote control point > SERVER_LU
LAN remote adapter address > 400000000001
APPN CP session support > *YES
APPN node type > *ENDNODE
APPN transmission group number > *CALC
This example has used a token ring line description named TRLAN. To
work with these line descriptions, use CRTLINTRN or CHGLINTRN. To
use other DLC types, use CRTLINSDLC, CRTLINX25, CHGLINSDLC,
CHGLINX25).
o Configuration changes specific to the client computer
No special configuration is needed for AS/400 to configure the ATELL
client.
o Configuration changes specific to the server computer
- Defining the TP To configure the server side for AS/400, all you have
to do is change the User Library List. The library where the ATELLD
program resides should be added to the list.
To access the User Library List:
-- Run the WRKSYSVAL command.
-- Page down until you find the QUSRLIBL system value, select 2 for
change.
-- Add the library (usually ATELL) to the list.
+---------------------------------------------------------------------------+
| |
| Configuration for AIX SNA Services |
| |
+---------------------------------------------------------------------------+
o General configuration tools
- Where and how configuration changes are made
Configuration for AIX SNA Services can be done through either SMIT
configuration panels, or importing ascii configuration files. The
examples shown below will be excerpts from an ascii configuration
file. You can either import these excerpts, or use them as a guide
while configuring using SMIT.
- How to make your configuration changes active
The proper sequence of commands to change your configuration and make
the changes active is:
stopsrc -s sna
importsna -l appc.pro
startsrc -s sna
o Configuration changes common to client and server computers
- Defining a local LU
The definition of a local LU involves defining a control point and a
local LU.
The control point definition should be:
CLIENT_LU_CONTROL POINT:
type = CONTROLPOINT
profile_name = LOCALCP
xid_node_id = 07100000
network_name = NETWORK_NAME
cp_name = CLIENT_LU
Where NETWORK_NAME and CLIENT_LU should be changed for your
environment.
The local LU definition should be:
CLIENT_LU_LOCAL LU:
type = LOCALLU
profile_name = LOCALLU
local_lu_name = CLIENT_LU
network_name = NETWORK_NAME
lu_type = lu6.2
independent_lu = yes
cp_sessions = no
tpn_list_name = LOCALTPS
local_lu_address = 1
sscp_id = *
number_of_rows = 24
number_of_columns = 80
- Defining a partner LU and Defining a link to a partner computer or to
the network node
The definition of a partner will require a number of steps:
1. Define the physical interface
This tells AIX SNA Services about the physical interface
characteristics.
For token ring, this can be done with:
LOCAL_TOKEN RING LOGICAL:
type = TOKENRINGLOGICAL
profile_name = LOCALLL
transmit_window_count = 10
dynamic_window_increment = 1
retransmit_count = 8
receive_window_count = 127
ring_access_priority = 0
inactivity_timeout = 75
drop_link_on_inactivity = yes
response_timeout = 2
acknowledgement_timeout = 1
force_disconnect_timeout = 120
link_trace = no
trace_entry_size = long
logical_link_type = token_ring
maximum_i_field = system_defined
maximum_i_field_size = 30729
physical_link_type = token_ring
LOCAL_TOKEN RING PHYSICAL:
type = TOKENRINGPHYSICAL
profile_name = LOCALPL
device_name = tok0
local_link_name = NONE
local_sap_address = 04
physical_link_type = token_ring
maximum_number_of_logical_links = 32
2. Define attachment profiles
These profiles specify the address and link characteristics for
connecting to your partner at the link level. There are
attachment profiles for incoming link activations (listen) and
outgoing link activations (call). In order to allow either side
to activate the link, you must define both a listen and a call
attachment profile. The listen attachment must be started before
the partner tries to activate the link by executing a command:
startsrc -t attachment -o LISTEN_PARTNER
The listen attachment is defined as follows:
LISTEN_ATTACHMENT:
type = ATTACHMENT
profile_name = LISTEN
control_point_profile_name = LOCALCP
logical_link_profile_name = LOCALLL
physical_link_profile_name = LOCALPL
logical_link_type = token_ring
stop_attachment_on_inactivity = no
station_type = secondary
physical_link_type = token_ring
remote_secondary_station_address = 1
smart_modem_command_sequence =
length_of_command_sequence = 0
call_type = listen
x25_level = 1984
listen_name = IBMQLLC
autolisten = yes
timeout_value = 0
remote_link_name_ethernet =
remote_link_name_token_ring =
remote_link_address =
selection_sequence =
length_of_selection_sequence = 0
network_type = switched
access_routing = link_address
remote_sap_address = 04
remote_sap_address_range_lower = 04
remote_sap_address_range_upper = EC
virtual_circuit_type = permanent
remote_station_X.25_address =
optional_X.25_facilities = no
logical_channel_number_of_PVC = 1
reverse_charging = no
rpoa = no
default_packet_size = yes
default_window_size = yes
default_throughput_class = yes
closed_user_group = no
closed_user_group_outgoing = no
network_user_id = no
network_user_id_name =
data_network_identification_code =
packet_size_for_received_data = 128
packet_size_for_transmit_data = 128
window_size_for_received_data = 4
window_size_for_transmit_data = 4
throughput_class_for_received_data = 1200
throughput_class_for_transmit_data = 1200
index_to_selected_closed_user_group = 0
lu_address_registration = no
lu_address_registration_name = LDEFAULT
The call attachment is defined as follows:
CALL_ATTACHMENT:
type = ATTACHMENT
profile_name = CALL
control_point_profile_name = LOCALCP
logical_link_profile_name = LOCALLL
physical_link_profile_name = LOCALPL
logical_link_type = token_ring
stop_attachment_on_inactivity = no
station_type = secondary
physical_link_type = token_ring
remote_secondary_station_address = 1
smart_modem_command_sequence =
length_of_command_sequence = 0
call_type = call
x25_level = 1984
listen_name = IBMQLLC
autolisten = no
timeout_value = 0
remote_link_name_ethernet =
remote_link_name_token_ring =
remote_link_address = 400000000001
selection_sequence =
length_of_selection_sequence = 0
network_type = switched
access_routing = link_address
remote_sap_address = 04
remote_sap_address_range_lower = 04
remote_sap_address_range_upper = EC
virtual_circuit_type = permanent
remote_station_X.25_address =
optional_X.25_facilities = no
logical_channel_number_of_PVC = 1
reverse_charging = no
rpoa = no
default_packet_size = yes
default_window_size = yes
default_throughput_class = yes
closed_user_group = no
closed_user_group_outgoing = no
network_user_id = no
network_user_id_name =
data_network_identification_code =
packet_size_for_received_data = 128
packet_size_for_transmit_data = 128
window_size_for_received_data = 4
window_size_for_transmit_data = 4
throughput_class_for_received_data = 1200
throughput_class_for_transmit_data = 1200
index_to_selected_closed_user_group = 0
lu_address_registration = no
lu_address_registration_name = LDEFAULT
3. Define the connection profiles
The connection profile specifies the LU name of the partner and
defines the name that will be used by the ATELL program to reach
the partner.
You will again need a connection profile for both listen and call
if you want to act as both a client and a server.
PARTNER_CONNECTION:
type = CONNECTION
profile_name = SERVER_LU_LISTEN
attachment_profile_name = LISTEN
local_lu_profile_name = LOCALLU
network_name = NETWORK_NAME
remote_lu_name = SERVER_LU
stop_connection_on_inactivity = no
lu_type = lu6.2
interface_type = extended
remote_tpn_list_name = REMOTETPS
mode_list_name = MODELIST
node_verification = no
inactivity_timeout_value = 0
notify = no
cp_sessions = no
parallel_sessions = parallel
negotiate_session_limits = yes
security_accepted = conversation
conversation_security_access_list_name =
PARTNER_CONNECTION:
type = CONNECTION
profile_name = SERVER_LU_CALL
attachment_profile_name = CALL
local_lu_profile_name = LOCALLU
network_name = NETWORK_NAME
remote_lu_name = SERVER_LU
stop_connection_on_inactivity = no
lu_type = lu6.2
interface_type = extended
remote_tpn_list_name = REMOTETPS
mode_list_name = MODELIST
node_verification = no
inactivity_timeout_value = 0
notify = no
cp_sessions = no
parallel_sessions = parallel
negotiate_session_limits = yes
security_accepted = conversation
conversation_security_access_list_name =
- Mode list profiles
You will also need mode list profiles:
MODE_MODE LIST:
type = MODELIST
Listname = MODELIST
list_members = BATCH,INTER
o Configuration changes specific to the client computer
No special configuration is needed for AIX SNA Services to configure the
ATELL client.
o Configuration changes specific to the server computer
- Defining the TP
To define the transaction program profiles:
LOCAL_TPN LIST:
type = TPNLIST
Listname = LOCALTPS
list_members = ATELLDLOCAL
ATELLDLOCAL_TPN:
type = TPN
profile_name = ATELLDLOCAL
tpn_name = ATELLD
conversation_type = mapped
pip_data = no
sync_level = confirm
recovery_level = no_reconnect
full_path_to_tpn = /u/pjs/bin/ATELLD
multiple_instances = yes
user_id = 0
server_synonym_name =
restart_action = once
communication_type = signals
stdin = /dev/null
stdout = /u/pjs/log/ATELLD.stdout
stderr = /u/pjs/log/ATELLD.stderr
subfields = 0
communication_ipc_queue_key = 0
tpn_name_in_hex = no
security_required = none
resource_security_access_list_name =
REMOTE_REMOTE TPN LIST:
type = REMOTETPNLIST
Listname = REMOTETPS
list_members = ATELLD
ATELLD_REMOTE TPN:
type = REMOTETPN
profile_name = ATELLD
tpn_name = ATELLD
pip_data = no
conversation_type = mapped
recovery_level = no_reconnect
sync_level = confirm
tpn_name_in_hex = no
+---------------------------------------------------------------------------+
| |
| Programmer's Guide |
| |
+---------------------------------------------------------------------------+
This is a quick guide on how to recompile the source code on your platform.
You should only need to refer to this section if you did not receive the
executable code with ATELL, or if you are interested in making changes to the
ATELL source.
See the appropriate makefile for your environment:
MAKEFILE ENVIRONMENT
ATELL.OS2 Networking Services/2 or Extended Services Only
This makefile will build an OS/2 only executable. You must have
the OS/2 Programmer's Toolkit installed. See the comments at the
start of the makefile for information about setting up your
compilation environment.
This makefile is written for Microsoft C 6.0. If you would like to
use it with IBM C/2, you will need to change the warning flag from
"/W4" to "/W3."
ATELL.FAM (Networking Services/2 or Extended Services) and Networking
Services/DOS
This makefile will build a family API executable that will run in
either OS/2 or a DOS environment. You must have the OS/2
Programmer's Toolkit installed, and both an OS/2 CPI-C platform
(Networking Services/2 or Extended Services) and Networking
Services/DOS See the comments at the start of the makefile for
information about setting up your compilation environment.
This makefile is written for Microsoft C 6.0. If you would like to
use it with IBM C/2, you will need to change the warning flag from
"/W4" to "/W3."
ATELL.DOS Networking Services/DOS Only
This makefile will build a DOS mode executable. The OS/2
Programmer's Toolkit is NOT required.
This makefile is written for Microsoft C 6.0. If you would like to
use it with IBM C/2, you will need to change the warning flag from
"/W4" to "/W3."
ATELL.BOR Networking Services/DOS Only
This makefile will build a DOS mode executable. The OS/2
Programmer's Toolkit is NOT required.
This makefile is for use with Borland C++ 2.0.
ATELL.400 AS/400
This file is a REXX exec which should be uploaded to the AS/400.
Assuming your compiler is set up to compile C code, you can simply
run this exec to build ATELL and ATELLD.
ATELL.AIX AIX SNA Services
This makefile is for use with the XCL compiler shipped with the AIX
operating system.
ATELL.VM VM ESA
This file is a REXX exec which should be uploaded to VM and renamed
(for example, to MAKEIT EXEC). Assuming your compiler is set up to
compile C code, you can simply run this exec to build ATELL and
ATELLD.
If you have access to a version of the MAKE utility, the ATELLVM
file also has a makefile for VM within comments at the end of the
file.